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(54) Downloading web pages 

(57) A method of enhancing sessions or applica- 
tions protocols which use successive transmission con- 
trol protocol (TCP) connections within a session on time 
division multiple access (TDMA) wireless packet data 
systems or wireline modem access protocols, wherein 
temporary block flows (TBFs) are chained. 

The present invention provides for a method and 



system for utilising sessions or applications protocols 
which use successive transmission control protocol 
connections within a session on time division multiple 
access wireless packet data systems or wireline modem 
access protocols. The method and system have the ad- 
vantages of reducing the download time for web pages 
and reducing the number of random access contentions 
experienced. 
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Description 

[0001] This invention relates to the downloading of 
web sites on time division multiple access (TDMA) wire- 
less packet data systems or wireline modem access 
protocols using sessions or applications protocols which 
use successive transmission control protocol (TCP) 
connections within a session. More specifically, this In- 
vention relates to methods of reducing the time over- 
head involved in such downloads, and reducing the 
number of random access contentions in such systems. 
[0002] When a client (web browser) initiates web ac- 
cess, a transmission control protocol/internet protocol 
(TCP/IP) connection is established between the client 
and the wob server, as shown in Figure 1 . The connec- 
tion Is established utilising what is known as a three-way 
handshake. Firstly, the client sends a SYN (synchronise 
idle character) signal to the server, which fn turn sends 
a SYN signal back to the client. The client then sends 
an acknowledgement signal to the server, thereby ac- 
knowledging receipt of the server's SYN signal and con- 
nection is complete. 

[0003] Once a connection has been established be- 
tween the client and the server, the client sends a hyper 
text mark-up language (HTML) request to the server. 
Such a request may be sent as a single TCP message 
or may be split into two such messages. The connection 
is characterised by what is termed a slow start mecha- 
nism. The client sends a single HTML request, awaits a 
response from the server, typically including the re- 
quested data, and sends an acknowledgement to the 
server. After transmission of the acknowledgement, 
multiple data signals are received from the server, such 
receipt is facilitated by the client. Once ail data is re- 
ceived, the server sends a finish signal. A finish ac- 
knowledgement signal is sent from the client to the serv- 
er, and then a finish signal. 

[0004] The downloading of a web page involves sev- 
eral TCP/IP connection establishment and tear down 
sequences. This is because, If the web page to be down- 
loaded comprises more than one inline image, a sepa- 
rate TCP session is required for the transfer of each im- 
age from the server to the client. Figure 1 illustrates this 
problem, whereby once the finished signal 1 02 has been 
transmitted by the client, the client parses (checks) the 
downloaded page to see if more data is required. For 
the example of Figure 1 , an image requires download- 
ing, so the above detailed connection establishment and 
tear down sequence is run again. In this instance, there 
is only a single data element which is less than 1 radio 
link control (BLC) packet to be sent, thus the server 
sends a single data signal followed by a finish signal. In 
this instance, the slow start mechanism is not invoked. 
[0005] It is thus clear that, in order to download a web 
page containing a plurality of images, a number of TCP 
connections must be made between a client and a serv- 
er. This is undesirable in terms of the time overhead for 
the overall download of a web page. 



[0006] There exists a problem in accessing the world- 
wide web (WWW) using sessions or applications proto- 
cols which use successive TCP connections within a 
session on TDMA wireless packet data systems or wire- 
5 line modem access protocols. This is illustrated herein- 
after with reference to the use of hyper text transfer pro- 
tocol (HTTP) on a global packet radio system (GPRS). 
When a browser sends an HTTP request, the request 
is transmitted as a SYN signal. However, every time a 
10 SYN signal is sent on GPRS there is a random access 
attempt made by the mobile station (MS) being utilised 
to connect to the network and thereby to a remote WWW 
server to facilitate the download of a required web page. 
[0007] Upon the occurrence of a random access at- 
tempt, the MS sends a message to the network, via a 
base transceiver station (BS), that It has data to send. 
When the MS receives a signal from the network that it 
may send data, the MS is allocated a number of packets 
of future time in which to send that data. However, if 
there are two requests made to the network at the same 
time, coilision of access attempts may occur. In this 
event, a SYN signal will not be transmitted by the net- 
work and the MS must make a further random access 
attempt later In time. This Is known as random access 
contention resolution. 

[0006] As will be explained below, the problem that 
exists is the necessity to establish a radio link control 
(RLC) link for every TCP/IP session. Radio link control 
is a protocol which controls the transfer of blocks of in- 
formation between the MS and network. It performs se- 
quenced delivery and error correction. The need to es- 
tablish separate radio links increases substantially the 
delays experienced by the user in downloading a web 
page and the images contained therein. Delays are fur- 
ther accentuated given that the current form of RLC pro- 
tocol requires that a countdown procedure is used to 
close down a link. Such a procedure consists of counting 
down the remaining number of blocks to be sent from a 
pre-set number to zero. The shutdown of the link occurs 
upon zero. 

[0009] The delays that occur during the download of 
a web page may best be appreciated by referring to Fig- 
ure 2, which shows a ladder diagram illustrating the 
message exchanges involved in the sending of a SYN 
message from client to server and from server to client. 
The following general assumptions have been made in 
the construction of the ladder diagram. It should be 
stressed that these assumptions are purely exemplary. 

1 . The majortime delays are attributed to temporary 
block flow (TBF) establishment and wide area net- 
work (WAN) and data transfertime, such as satellite 
delay when making a transatlantic connection, for 
example. 

2. The time overhead for the creation of an uplink 
TBF is larger than the time overhead for the creation 
of an uplink TBF whilst the downlink TBF is active. 
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3. The establishment of a downlink TBF has a time 
overhead less than that for the establishment of an 
uplink TBF. 

4. Data transfers have an associated block error 
rate (BLER) of 10%. 

5. The RLC roundtrlp delay for data transfers Is 10 
RLC blocks. 

6. Data is transferred at the lowest code rate (high- 
est throughput). 

[0010] The terminology used within these assump- 
tions will become clearer In the light of the following de- 
scription relating to Figure 2. 

[0011 J As may be seen in Figure 2, the connection be- 
tween web browser and remote server on a GPRS in-; 
volves various layers of control which interact with one 
another to enable communication links to be created. A 
browser communicates via a transmission control pro- 
tocol (TCP) layer, which communicates with a logical 
link control (LLC) layer, which communicates with the 
mobile station radio link control (RLC-MS) layer. From 
here, messages are broadcast from MS to BS across a 
radio link formed therebetween. Messages received at 
the base station radio link control (RLC-BS) level are 
communicated to a logical link control/transmfssion con- 
trol protocol (LLC/TCP) layer and thereon to the TCP 
layer of the remote server. Of course, this operates in 
reverse also. 

[001 2] Referring again to Figure 2, the browser sends 
a HTTP request 2 which is sent as a SYN signal 4 by 
the TCP layer, this signal is sent on as a set synchronise 
balance mode (SABM) signal 6, by the LLC layer to the 
RLC-MS layer. At this stage an uplink TBF 10, a con- 
nection between MS and BS for the transfer of informa- 
tion in terms of RLC blocks, is established. - 
[0013] After establishment of the uplink, a TCP signal 
is passed on from the RLC-BS layerto the LLC/TCP lay- 
er as a connection indication (Conn-ind) signal 12. An 
acknowledgement signal 1 4 is sent back from this layer 
to the LLC layer which in turn sends an information 
frame 16, comprising TCP information and a SYN sig- 
nal, back to the LLC/TCP layer. The next stage involves 
the sending of a SYN signal 1 8 from the LLC/TCP layer 
to the TCP remote server. This then sends a SYN signal 
20 back, which is transmitted onwards to the RLC-BS 
as an SABM signal 22. 

[001 4] Now a downlink TBF-oonnection for transmittal 
of RLC blocks from BS to MS is established. This step 
is generally indicated as 24. After downlink establish- 
ment, a connection indication (Conn-ind) signal 26 is 
sent onwards to the LLC layer. This is acknowledged by 
acknowledgement signal 2B which passes across the 
air interface between MS and BS to the LLC/TCP layer. 
From there an information frame is sent across the radio 
link and onwards to the browser TCP layer. 
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[0015] Here it is assumed that the downlink TBF is 
closed after polling using the related reserved block pe- 
riod (RRBP). A BS may send a message with the RRBP 
set so that the MS must respond with an acknowledge- 
s ment signal at the RLC level within a certain number of 
RLC blocks. If the RRBP does not require that the down- 
link remain open for such an acknowledgement, the 
downlink will be closed. 

[0016] It is clear to see that these two signals, the first 

w two depicted in Figure 1 , have taken a specific time (x) 
to be passed. Such a connection must be made a 
number of times in any one web page download opera- 
tion. There is thus a problem in that the requirements 
for downloading web pages using HTTP on a GPRS can 

15 be very high. The stated problem becomes more signif- 
icant when exemplified with regard to time periods. For 
the download of a single web page containing no imag- 
es, three connection and tear down sequences must be 
carried out. One to establish that data Is required, one 

20 to notify the server of what data is required and to re- 
ceive the data, and a final one to acknowledge. Obvi- 
ously, this will increase by the duration of a further con- 
nection and teardown sequence for every image to be 
downloaded. The problem requiring a solution is, there- 

25 fore, how to reduce the time requirements for download- 
ing a web page using sessions or applications protocols 
which use successive TCP connections within a session 
on TDMA wireless packet data systems or wireline mo- 
dem access protocols, thus increasing efficiency and 

30 user satisfaction. 

[0017] The present invention aims to address some 
or all of the above disadvantages. 
[0018] The present invention provides as claimed in 
the appendant claims, a method for enhancing sessions 

35 or applications protocols which use successive trans- 
mission control protocol (TCP) connections within a ses- 
sion on time division multiple access (TDMA) wireless 
packet data systems or wireline modem access proto- 
cols, wherein temporary block flows (TBFs) are chained. 

40 The present invention also provides methods for the re- 
duction of web page download time and for the reduction 
of random access contentions in time division multiple 
access (TDMA) wireless packet data systems or wire- 
line modem access protocols, and time division multiple 

<* access (TDMA) wireless packet data systems or wire- 
line modem access protocols all utilising TBF chaining. 
[0019] According to a preferred embodiment of the 
present invention, there is provided a method wherein 
an existing downlink TBF is utilised to request a rendez- 

50 vous point from a network. 

[0020] In another aspect of the present invention, 
there is provided a method wherein an existing uplink is 
utilised to request a rendezvous point from a network, 
prior to its closure. . 

55 [0021] In another aspect of the present invention, 
there is provided a method wherein a network maintains 
a downlink TBF constantly active. 
[0022] The different aspects of the present invention 
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may be utilised separately, or in any combination. They 
may also utilise the steps of determining the number of 
TCP sessions required to download an entire web page, 
and thereby transmitting information relating to the re- 
maining number of required TBFs to a network. 
[0023) Additional specific advantages of the present 
invention are apparent from the following description of 
Figures In which: 

Figure 1 shows the messages exchanged between 
a client and a server during the download of a web 
page; 

Figure 2 shows the messages exchanged during 
the first two signals in a three-way handshake using 
HTTP on a GPRS; 

Figure 3 shows a ladder diagram depicting the sce- 
nario in which a connection between client and host 
remains open; 

Figure 4 shows a ladder diagram depicting a ren- 
dezvous request; 

Figure 5 shows a flow diagram illustrating a time lo- 
cation catcutation for the rendezvous of Figure 4; 
Figure 6 shows a flow diagram illustrating a method 
of TBF chaining using a closing uplink; 
Figure 7 shows a flow diagram illustrating a time lo- 
cation calculation for the rendezvous point of Figure 
6; 

Figure 8 shows a flow diagram illustrating a method 
of TBF chaining wherein a downlink remains always 
active; and 

Figure 9 shows a flow diagram illustrating a method 
of informing a network of status information. 

[0024] The present invention Is now described with 
reference to the accompanying drawings as detailed 
above. 

[0025] The present invention operates upon the basis 
that, if a TBF remains active in some way, even when 
no data is being transferred, there will not be required a 
stand alone TBF establishment for each communication 
between the MS and the network. This is termed TBF 
chaining. 

[0026] As may be seen from Figure 3, once an uplink 
TBF has been established, 302, 304, 306 between the 
RLC-MS and RLC-BS of the client and server, an HTML 
request may be sent- 308 which will result in data and 
finish signal 31 0, 31 2 being passed back from the server 
to the client. At this stage, the uplink TBF remains active. 
It is thus possible for transmission 31 8 to occur thereaf- 
ter, after a RLC/MAC channel resource assignment pro- 
cedure. There is no need to create an uplink TBF con- 
nection with its associated time overheads. This result 
is achieved in a number of different ways which are de- 
scribed below with reference to Figures 4 to 9. 
[0027] Figure 4 shows the messages passed be- 
tween an MS and a BS when a downlink TBF is used to 
request a rendezvous point from an uplink TBF. Figure 
4 is representative of an extract of a ladder diagram 



showing messages passed between an MS and BS. The 
first signal 402, an LLC levei signal, passed from BS to 
MS is representative of the last communication sent 
through an established downlink from a BS to an MS. 

s After receipt of this signal, and prior to downlink closure, 
the MS sends a request for a rendezvous, an RLC level 
signal. In other words, the MS sends a message back 
through the downlink, before its closure, Indicating that 
it may want to transmit something based upon TCP/HT- 

to TP conditions. In effect, when RRBP is polled (c.f. Fig- 
ure 2), the MS sends a message to the BS requesting 
resource. The MS provides details of the minimum 
number of RLC blocks before the expiry of which it will 
not be ready to transmit data. In response to this, the 
,. is BS allocates a contention free resource forthis purpose. 
This resource consists of a block of time allocated solely 
for the use of the MS. The block is located a certain 
number of RLC blocks after request and is named a ren- 
dezvous point. 

20 [0028] The block allocated for the use of the MS en- 
ables the MS to inform the BS of whether it has any more 
data to transmit. Thus, the MS may use this block to re- 
quest necessary resource for data to be transferred from 
the server to a client, or to Indicate that it has nothing 

25 further to transmit, or to request a further rendezvous 
point. 

[0029] This procedure reduces the time to create an 
uplink TBF from the uplink TBF establishment time 
(standalone) to the time taken to create an uplink TBF 

30 through a downlink TBF. However, it should be noted 
that the bandwidth of the allocated RLC block is wasted 
if the MS has nothing further to transmit when the ren- 
dezvous point is reached, and thus does not use the al- 
located RLC block. Additionally, the number of random 

35 access contentions occurring is reduced because re- 
source for an uplink request has already been allocated. 
[0030] The time for which the rendezvous point is re- 
quested is calculated using time and data which the MS 
maintains. The MS maintains a timing record per each 

40 web or internet protocol (IP) address (or for a limited 
number of addresses in a circular storage area). It also 
maintains a timing record at the radio link control/media 
access control (RLC/MAC) level (previously termed 
solety RLC) for the network currently in service. For 

« each IP address, the RLC/MAC network interface used 
during the measurement is stored, in order to maintain 
such records, the MS measures the following timings 
when they are required and in accordance with what is 
allowed by the various protocols involved. The MS may 

50 use any method for maintaining measurements. Such 
methods may include averaging over a number of pre- 
vious measurements or simply using the latest meas- 
urements: 

55 1 . The stand alone uplink establishment time. This 
is the RLC/MAC uplink TBF establishment time, 
and is the time between the first random access at- 
tempt and the receipt of a "packet assignment" mes- 
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sage (a message indicating the assignment of re- 
sources for transmission of data on an uplink). 

2. The stand alone downlink establishment time. 
This is the time between the receipt of a "packet 
downlink assignment" message and the receipt of 
a first valid RLC block. 

3. The uplink TBF establishment time whilst a down- 
link TBF is still active. 

4. The downlink TBF establishment time whilst an 
uplink TBF remains active; and 

5. The TCP roundtrip time. This is the time for a TCP 
message to be transmitted from the TCP layer of a 
client or MS, to the TCP layer of a server (remote 
or otherwise) and back to the MS. 

[0031] In addition to the above parameters, the MS 
also takes into consideration the uplink and downlink da- 
ta rates and their respective block error rates when de- 
termining the desired time for rendezvous point loca- 
tions. 

[0032] Figure 5 illustrates how an MS of the embodi- 
ment of Figure 4 requests a rendezvous point. In func- 
tion box 502,' the MS determines whether more data 
needs sending and also the size of the remaining data. 
This is determined from the condition of the HTTP and/ 
or the TCP. This can occur at any time in which a down- 
link TBF is active. 

[0033] In function box 504, the MS waits until It knows 
the size of the downlink TCP message which is currently 
being sent. The MS then calculates the time at which it 
should have received the complete downlink message, 
taking into consideration the downlink data rate and 
block error rate. The calculation also takes into account 
the messages which need to be transacted at different 
levels of control within the client/server interface. 
[0034] Function box 506 details the resource request 
transmission step. Here the MS transmits a request for 
1 RLC block of uplink at a rendezvous point equal to the 
time determined in function box 504. The TCP roundtrip 
time is used as a benchmark to prevent the rendezvous 
point from being requested for a time that is too early. If 
the requested point fails at a time sooner than a TCP 
roundtrip time, the network would be ready to establish 
resources before there is anything to send. Similarly, if 
the time until the rendezvous point is much longer than 
either of the RLC uplink TBF establishment times, or if 
the uplink TBF is active, the request is not sent. The 
network reserves the right to allow, delay, or reject any 
request for resource. 

[0035] Function box 508 depicts a decision which is 
made by the MS. If, after the number of blocks between 
the rendezvous request and the allocated block, the MS 
has more data to transmit, then that data is transmitted 
to the 8S, as detailed in function box 510. However, if 



the MS has no further data to transmit it is determined 
(function box 512) whether rendezvous requests are al- 
lowed. This is done by the MS listening to the network's 
system information messages which are broadcast con- 
s tinuously. The network sets a bit within these messages 
to indicate whether rendezvous requests are accepted. 
The MS will listen to this information before making a 
call. 

[0036] If rendezvous requests are accepted, it Is es- 
10 tablished (function box 514) whether rendezvous re- 
quest retries are allowed. This information is available 
in the same way as detailed for whether rendezvous re- 
quests are accepted. 

[0037] If both requests and retries are accepted, func- 
15 tion box 502 is returned to. However, if either, or both, 
of these requests are not accepted by the network, com- 
munication between the MS and network comes to an 
end (function box 51 6). 

[0038] A second method of chaining TBFs is depicted 
20 in Figures. In this method, an MS utilises the countdown 
procedure of the RLC level in requesting a rendezvous 
point for the next uplink TBF. 

[0039] Function box 602 indicates the RLC count- 
down. The RLC protocol requires that as the MS starts 

25 to have fewer blocks of data to send, it must inform the 
network. As such, a countdown, from a pre-set number 
of blocks remaining to be transmitted, to zero, is earned 
out. This allows the network to be informed of how much 
data remains, and when transmission will be completed. 

so When the count reaches zero, the end of the data Is also 
reached. In this embodiment, the MS parallels the 
countdown and, when the countdown is equal to zero 
(function box 604), the MS sends a request for a single 
resource to be allocated. The block is requested to' be 

35 allocated at a future time, for the purpose of requesting 
data transfer. As such, the MS indicates a rendezvous 
point for the allocation of a block. This is carried out at 
the same time as the existing uplink TBF is closed. 
Whilst the countdown is not equal to zero, the MS takes 

40 no action in this regard (function box 608). 

[0040] This method is advantageous in that as a block 
has already been allocated for requesting resource for 
the next uplink TBF, the contention resolution procedure 
Inherent in random access attempts, as explained ear- 

*s lier, is avoided. This reduces the time overhead for es- 
tablishing further uplink TBFs (i.e. uplinks established 
after the first or primary uplink) from the standalone up- 
link establishment duration to that of the uplink estab- 
lishment through an open downlink. 

so [0041] The rendezvous request procedure utilised in 
the embodiment of Figure 6 uses the same parameters 
as that of Figure 5. However, the process of requesting 
a rendezvous point differs and is described with refer- 
ence to Figure 7. 

55 [0042] Function box 702 depicts the first step in the 
process of requesting a rendezvous point. This step re- 
quires that knowledge of the current TCP roundtrip time 
is available for use. The MS calculates the time elapsed 
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since the start of the current TCP message at the point 
in time where the decision to request a rendezvous point 
is made, which is ascribed the symbol T E . The next step, 
detailed in function box 704, takes place when the RLC 
countdown has reached zero. Mere, the MS requests a 
rendezvous point at a future time given as the difference 
between the TCP roundtrip time (T TC p R ) and time value 
calculated in step 702. Again, the network reserves the 
right to either admit, delay or reject the received request. 
Function box 706 details the decision taken by the MS 
as to whether or not it has further data to transmit, in the 
form of an acknowledgement signal or request for re- 
source for example, when the rendezvous point is 
reached. If the MS has further data, that data is trans- 
mitted as shown in function box 708. Otherwise, it is de- 
termined (function box 71 0) whether rendezvous re- 
quests are allowed. This is done by the MS listening to 
the network's system information messages which are 
broadcast continuously. The network sets a bit within 
these messages to indicate whether rendezvous re- 
quests are accepted. The MS will listen to this Informa- 
tion before making a call. 

[0043] If rendezvous requests are accepted, it is es- 
tablished (function box 712) whether rendezvous re- 
quest retries are allowed. This information is available 
in the same way as detailed for whether rendezvous re- 
quests are accepted. 

[0044] If both requests and retries are accepted, func- 
tion box 502 is returned to. However, if either, or both, 
of these requests are not accepted by the network, com- 
munication between the MS and network comes to an 
end (function box 714), It should be noted that one or 
more correction factors may be utilised within this pro- 
cedure. 

[0045] A third method of chaining TBFs, wherein a 
network retains an open downlink TBF at all times, is 
described with reference to Figure 8. As may be seen 
from Figure 8, this method relies upon the downlink TBF 
(c.f. 24, Figure 2) being kept open by a BS after an HTTP 
or TCP/IP session transaction has been carried out. 
[0046] Function box 802 details the step of the BS re- 
ceiving an estimate from the MS of the minimum number 
of future RLC blocks before which it will not be able to 
transmit further data. This information is sent as often 
as the MS can send it along with information detailing 
the current roundtrip TCP delay being experienced. 
[0047] The next step 804 consists of the BS polling 
the MS periodicaiiy to see whether the MS has made 
any uplink resource requests. If a request has been 
made, an uplink TBF is established 806, 808 at the 
smaller of the two establishment overheads detailed 
earlier because the downlink TBF remains open. If no 
request has been made, the BS continues to poll the MS 
periodically. 

[0048] This method provides a network control proce- 
dure. If a BS is, at a particular time, dealing with a high 
proportion of network traffic, it may choose not to poll 
an MS for resource requests. The BS may delay the time 



when it will next poll an MS. Thus, this method provides 
a mechanism controlled by the network for dealing with 
collisions. Random access contentions maybe avoided, 
because when they are likely to occur, the BS merety 
5 delays the polling of the MS. A contention free resource 
is therefore provided. This method provides the same 
time saving as the previous methods. 
[0049] A final method, complementary to the chaining 
of TBFs, is detailed in Figure 9. This method may be 
io used with any of the above three methods of chaining. 
This method begins in an MS. The MS, step 902, deter- 
mines the number of TCP connections/tear down se- 
quences which will be required in order to download a 
web page. As already explained, an individual sequence 
is is required for each inline image to be downloaded. This 
step utilises HTTP page parsing. 
[0050] In function box 904, an indication of the 
number of TBFs still requiring establishment in order to 
complete the download is passed to the network. This 
indication is made by means of a counter. In addition, 
the MS can indicate the number of octets (bytes) of data 
that it may have to transfer on the uplink in future TBFs. 
This occurs particularly in uploads wherein the nature 
of events Is sfmilar. 

[0051] The above methods may all be employed to- 
gether to provide TBF chaining in download of web pag- 
es using HTTP on a GPRS. However, the most likely 
and preferred combinations are the embodiments of 
Figures 4, 8 and 9, and the embodiments of Figures 6, 
8 and 9. 

[0052] The above methods, however combined, 
serve to reduce the time overhead of TBF establishment 
using HTTP in a GPRS. The gains achieved by the use 
of TBF chaining, In an exemplary download scenario, 
are now described. In the download of a page containing 
four images, five TCP connections would be required. 
One for the page, and one for each image. For each of 
these connections there will be up to four uplink TBF 
establishments and up to three down link TBF establish- 
ments. It is thus obvious that reducing the time taken to 
establish each such link wifl significantly reduce the 
overall time overhead for a download. Also, as HTTP 
improves, bottlenecks will only remain in the form of the 
TCP roundtrip time for connection establishment and 
stow start. Further, chaining TBFs provides noticeable 
improvements in the most desirous area. 
[0053] There is also a band width gain associated with 
TBF chaining. As the number of messages exchanged 
between control levels in both client and server (i.e. in 
order to establish a connection) is reduced, fewer RLC 
blocks are required in order to connect. Thus, mere RLC 
blocks are available to the user for data transfer, etc. 
Further, the reduction in the number of random access 
contentions results in a significant reduction in colli- 
sions, which has an associated saving in time, as pre- 
viously described. , 

[0054] The above detailed description provides for 
methods of improving the use of HTTP on GPRS's and 
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GPRS systems utilising such methods, for predicting 
rendezvous points, and for avoiding collisions and con- 
tention resolution in a GPRS utilising HTTP. These 
methods have been described as relating to GPRS, but 
apply equally to any time division multiple access (TD- 5 
MA) wireless packet data system and any wireline mo- 
dem access protocol. Further, whilst the methods and 
systems of this invention have been described with ref- 
erence to hyper text transfer protocol, they apply equally 
to any sessions or applications protocols utilising sue- "> 
cessive transmission control protocol (TCP) connec- 
tions within a session. 

[0055] It will be of course be understood that the 
present invention has been described by way of exam- 
ple only, and that modifications of detail may be made is 
without departing from the scope of the Invention. 

Claims 

20 

1. A method of enhancing sessions or applications 
protocols which use successive transmission con- 
trol protocol (TCP) connections within a session on 
time division multiple access (TDMA) wireless 
packet data systems and wireline modem access 25 
protocols, wherein temporary block flows (TBFs) 

are chained. 

2. A method of reducing the download time of a web 
page using sessions or applications protocols 30 
which use successive TCP connections within a 
session on TDMA wireless packet data systems 
and wireline modem access protocols, wherein 
temporary block flows (TBFs) are chained. 

35 

3. A method of reducing the number of random access 
contentions in TDMA wireless packet data systems 
and wireline modem access protocols using ses- 
sions or applications protocols which use succes- 
sive TCP connections within a session, wherein <o 
temporary block flows (TBFs) are chained. 

4. A method according to any preceding claim, where- 
in the sessions or applications protocols include hy- 
per text transfer protocol (HTTP) and the TDMA « 
wireless packet data system and wireline modem 
access protocols include global packet radio sys- 
tems (GPRSs) and enhanced GPRSs (EGPRSs). 

5. A method according to any preceding claim, com- so 
prising: utilising an existing do wnlinkTBF to request 

a rendezvous point from a network. 

6. A method according to claim 5, wherein said ren- 
dezvous point Is requested to be located at a point 55 
in time when an uplink TBF may be required. 

7. A method according to claim 6, wherein the rendez- 



vous point location is calculated, said calculation 
comprising the steps of: 

determining whether further data needs send- 
ing to the network, and determining the size of 
the data; and 

estimating the time when the current downlink 
signal should be complete. 

8. A method according to any of claims 5 to 7, wherein 
the rendezvous point comprises a single radio link 
control (RLC) block of uplink. 

9. A method according to claim 8, further comprising 
the step of, if the rendezvous point is allowed by the 
network, when the rendezvous point Is reached, 
and if data to be transmitted is present, utilising the 
block of uplink to request an uplink TBF. 

10. A method according to any of claims 1 to 4, com- 
prising: utilising an existing uplink TBF to request a 
rendezvous point from a network. 

11. A method according to claim 10, wherein the re- 
quest is made as data transmission ends. 

12. A method according to either of claims 10 or 11, 
wherein the request is made as an RLC counter 
reaches zero. 

13. A method according to any of claims 10 to 12, 
wherein the rendezvous point is requested to be lo- 
cated at a point in time when an uplink TBF may be 
required. 

14. A method according to any of claims 10 to 13, 
wherein the rendezvous point is calculated accord- 
ing to the following steps: 

calculating the time lapsed since transmission 
of a current TCP message; and 
estimating the rendezvous point as the differ- 
ence between the elapsed time and a TCP 
roundtrip time taking account of any required 
correction factors. 

15. A method according to any of claims 10 to 14, 
wherein the rendezvous point comprises a single 
RLC block of uplink. 

16. A method according to claim 15, further comprising 
the step of, if the rendezvous point is allowed by the 
network, when the rendezvous point is reached, 
and if data to be transmitted is present, utilising the 
block of uplink to request an uplink TBF. 

17. A method according to claim 9 or claim 16, further 
comprising the steps of: 
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if the rendezvous point is rejected by the net- 
work, determining whether rendezvous re- 
quests are accepted by the network; 
if rendezvous requests are accepted by the net- 
work, determining whether re-requests are ac- s 
cepted by the network; and 
if re-requests are allowed, repeating the ren- 
dezvous request procedure. 

18. A method according to any of claims 1 to 4, com- io 
prising the step of a network maintaining a downlink 
TBF as active. 

19. A method according to claim 18, further comprising 
the steps of: 1 $ 

receiving an estimate from a mobile station 
(MS) of the minimum number of RLC blocks be- 
fore which it will have nothing to transmit; and 
polling the MS for an uplink resource request. 20 

20. A method according to claim 19, comprising the 
step of, if a resource request is identified, opening 
an uplink TBF between the MS and the BS. 

25 

21 . A method according to any of claims 4 to 1 7, where- 
in a network to which a request for a rendezvous 
point has been made may accept, reject, or delay . 
the request. 

30 

22. A method according to any of claims 4 to 21 , further 
comprising the steps of: 

determining the number of TCP sessions re- 
quired to download a web page; 35 
and 

transmitting an indication of the remaining re- 
quired TBFs to a network. 

23. A method according to claim 22, further comprising *o 
the steps of transmitting to the network an estimate 

of th e s iz e of th e data to be uploaded in future TB Fs . 

24. A TDM A wireless packet date system or wireline 
modem access protocol which uses a method ac- & 
cording to any preceding claim. 

25. A TDM A wireless packet data system or wireline 
modem access protocol comprising means for 
chaining TBFs. 50 
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